Live migration of virtual computing instances between data centers

ABSTRACT

A method of migrating a virtualized computing instance between source and destination virtualized computing systems includes executing a first migration workflow in the source virtualized computing system between a source host computer and a first mobility agent simulating a destination host, executing a second migration workflow in the destination virtualized computing system between a second mobility agent simulating a source host and a destination host computer, sending, as part of the first migration workflow, a configuration of the migrated virtualized computing instance to the destination virtualized computing system, translating, as part of the second migration workflow, infrastructure-dependent information in the configuration of the migrated virtualized computing instance, and transferring, during execution of the first and second migration workflows, migration data including the virtualized computing instance between the source host and the destination host over a network.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application claims the benefit of U.S. Provisional PatentApplication No. 62/380,944, filed Aug. 29, 2016, the entire contents ofwhich are incorporated by reference herein.

BACKGROUND

Cloud architectures are used in cloud computing and cloud storagesystems for offering infrastructure-as-a-service (IaaS) cloud services.Examples of cloud architectures include the VMware vCloud Director®cloud architecture software, Amazon EC2™ web service, and OpenStack™open source cloud computing service. IaaS cloud service is a type ofcloud service that provides access to physical and/or virtual resourcesin a cloud environment. These services provide a tenant applicationprogramming interface (API) that supports operations for manipulatingIaaS constructs, such as virtual machines (VMs) and logical networks.

A hybrid cloud system aggregates the resource capability from bothprivate and public clouds. A private cloud can include one or morecustomer datacenters (referred to herein as “on-premise datacenters”).The public cloud can include a multi-tenant cloud architecture providingIaaS cloud services. In a hybrid cloud system, it is desirable tosupport VM migration between the datacenter and the public cloud.Presently, to implement VM migration, a customer must first create a VMfrom scratch within the public cloud and then transfer data from apowered-off source VM in the on-premise datacenter to the newly createdVM in the public cloud. This process has the disadvantage of significantdowntime for the VM being migrated.

SUMMARY

One or more embodiments provide techniques for virtual computinginstance migration between data centers. In an embodiment, a method ofmigrating a virtualized computing instance between source anddestination virtualized computing systems includes: executing a firstmigration workflow in the source virtualized computing system, where ahost computer in the source virtualized computing system executing thevirtualized computing instance is a source host in the first migrationworkflow and a first mobility agent in the source virtualized computingsystem simulates a destination host in the first migration workflow;executing a second migration workflow in the destination virtualizedcomputing system, where a second mobility agent in the destinationvirtualized computing system simulates a source host in the secondmigration workflow and a host computer in the destination virtualizedcomputing system is a destination host in the second migration workflow;sending, as part of the first migration workflow, a configuration of thevirtualized computing instance to the destination virtualized computingsystem; translating, as part of the second migration workflow,infrastructure-dependent information in the configuration of thevirtualized computing instance; and transferring, during execution ofthe first and second migration workflows, migration data including thevirtualized computing instance between the source host and thedestination host over a network.

Further embodiments include a non-transitory computer-readable storagemedium comprising instructions that cause a computer system to carry outthe above method, as well as a computer system configured to carry outthe above method.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a hybrid cloud computing system in whichone or more embodiments of the present disclosure may be utilized.

FIG. 2 is a block diagram showing logical connections and dataflow amongvarious components in hybrid cloud with respect to a cross-cloud VMmigration according to an embodiment.

FIG. 3 is a flow diagram depicting an embodiment of a method ofmigrating a virtualized computing instance, such as a VM, between sourceand destination virtualized computing systems, such as betweenon-premise datacenter and cloud computing system.

FIG. 4 is a flow diagram depicting a method of preparing cross-cloud VMmigration according to an embodiment.

FIG. 5 is a flow diagram depicting an example of a method for processingVM configuration information.

FIG. 6 is a block diagram depicting an example of a computer system inwhich one or more embodiments of the present disclosure may be utilized.

To facilitate understanding, identical reference numerals have beenused, where possible, to designate identical elements that are common tothe figures. It is contemplated that elements disclosed in oneembodiment may be beneficially utilized on other embodiments withoutspecific recitation.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of a hybrid cloud computing system 100 inwhich one or more embodiments of the present disclosure may be utilized.Hybrid cloud computing system 100 includes a virtualized computingsystem implementing an on-premise datacenter 102 and a virtualizedcomputing system implementing a cloud computing system 150. Hybrid cloudcomputing system 100 is configured to provide a common platform formanaging and executing virtual workloads seamlessly between on-premisedatacenter 102 and cloud computing system 150. In one embodiment,on-premise datacenter 102 may be a data center controlled andadministrated by a particular enterprise or business organization, whilecloud computing system 150 may be operated by a cloud computing serviceprovider and exposed as a service available to account holders, such asthe particular enterprise in addition to other enterprises. As such,on-premise datacenter 102 may sometimes be referred to as a “private”cloud, and cloud computing system 150 may be referred to as a “public”cloud.

As used herein, an internal cloud or “private” cloud is a cloud in whicha tenant and a cloud service provider are part of the same organization,while an external or “public” cloud is a cloud that is provided by anorganization that is separate from a tenant that accesses the externalcloud. For example, the tenant may be part of an enterprise, and theexternal cloud may be part of a cloud service provider that is separatefrom the enterprise of the tenant and that provides cloud services todifferent enterprises and/or individuals. In embodiments disclosedherein, a hybrid cloud is a cloud architecture in which a tenant isprovided with seamless access to both private cloud resources and publiccloud resources.

On-premise datacenter 102 includes one or more host computer systems(“hosts 104”). Hosts 104 may be constructed on a server grade hardwareplatform 106, such as an x86 architecture platform. As shown, hardwareplatform 106 of each host 104 may include conventional components of acomputing device, such as one or more processors (CPUs) 108, systemmemory 110, a network interface 112, storage system 114, and other I/Odevices such as, for example, a mouse and keyboard (not shown). CPU 108is configured to execute instructions, for example, executableinstructions that perform one or more operations described herein andmay be stored in memory 110 and in local storage. Memory 110 is a deviceallowing information, such as executable instructions, cryptographickeys, virtual disks, configurations, and other data, to be stored andretrieved. Memory 110 may include, for example, one or more randomaccess memory (RAM) modules. Network interface 112 enables host 104 tocommunicate with another device via a communication medium, such as anetwork 122 within on-premise datacenter 102. Network interface 112 maybe one or more network adapters, also referred to as a Network InterfaceCard (NIC). Storage system 114 represents local storage devices (e.g.,one or more hard disks, flash memory modules, solid state disks, andoptical disks) and/or a storage interface that enables host 104 tocommunicate with one or more network data storage systems. Examples of astorage interface are a host bus adapter (HBA) that couples host 104 toone or more storage arrays, such as a storage area network (SAN) or anetwork-attached storage (NAS), as well as other network data storagesystems.

Each host 104 is configured to provide a virtualization layer thatabstracts processor, memory, storage, and networking resources ofhardware platform 106 into multiple virtual machines 120 ₁ to 120 _(N)(collectively referred to as VMs 120) that run concurrently on the samehosts. VMs 120 run on top of a software interface layer, referred toherein as a hypervisor 116, that enables sharing of the hardwareresources of host 104 by VMs 120. One example of hypervisor 116 that maybe used in an embodiment described herein is a VMware ESXi™ hypervisorprovided as part of the VMware vSphere® solution made commerciallyavailable from VMware, Inc. of Palo Alto, Calif. Hypervisor 116 may runon top of the operating system of host 104 or directly on hardwarecomponents of host 104.

On-premise datacenter 102 includes a virtualization management component(depicted in FIG. 1 as virtualization manager 130) that may communicateto the plurality of hosts 104 via a network, sometimes referred to as amanagement network 126. In one embodiment, virtualization manager 130 isa computer program that resides and executes in a central server, whichmay reside in on-premise datacenter 102, or alternatively, running as aVM in one of hosts 104. One example of a virtualization manager is thevCenter Server™ product made available from VMware, Inc. Virtualizationmanager 130 is configured to carry out administrative tasks forcomputing system 102, including managing hosts 104, managing VMs 120running within each host 104, provisioning VMs, migrating VMs from onehost to another host, and load balancing between hosts 104.

In one embodiment, virtualization manager 130 includes a hybrid cloudmanagement module (depicted as hybrid cloud manager 132) configured tomanage and integrate virtualized computing resources provided by cloudcomputing system 150 with virtualized computing resources of computingsystem 102 to form a unified “hybrid” computing platform. Hybrid cloudmanager 132 is configured to deploy VMs in cloud computing system 150,transfer VMs from virtualized computing system 102 to cloud computingsystem 150, and perform other “cross-cloud” administrative tasks, asdescribed in greater detail later. In one implementation, hybrid cloudmanager 132 is a module or plug-in complement to virtualization manager130, although other implementations may be used, such as a separatecomputer program executing in a central server or running in a VM in oneof hosts 104. One example of hybrid cloud manager 132 is the VMwarevCloud Connector® product made available from VMware, Inc.

In one embodiment, hybrid cloud manager 132 is configured to controlnetwork traffic into network 122 via a gateway component (depicted as agateway 124). Gateway 124 (e.g., executing as a virtual appliance) isconfigured to provide VMs 120 and other components in on-premisedatacenter 102 with connectivity to an external network 140 (e.g.,Internet). Gateway 124 may manage external public IP addresses for VMs120 and route traffic incoming to and outgoing from on-premisedatacenter 102 and provide networking services, such as firewalls,network address translation (NAT), dynamic host configuration protocol(DHCP), load balancing, and virtual private network (VPN) connectivityover a network 140.

In one or more embodiments, cloud computing system 150 is configured todynamically provide an enterprise (or users of an enterprise) with oneor more virtual data centers 170 in which a user may provision VMs 120,deploy multi-tier applications on VMs 120, and/or execute workloads.Cloud computing system 150 includes an infrastructure platform 154 uponwhich a cloud computing environment 170 may be executed. In theparticular embodiment of FIG. 1, infrastructure platform 154 includeshardware resources 160 having computing resources (e.g., hosts 162 ₁ to162 _(N)), storage resources (e.g., one or more storage array systems,such as SAN 164), and networking resources, which are configured in amanner to provide a virtualization environment 156 that supports theexecution of a plurality of virtual machines 172 across hosts 162. It isrecognized that hardware resources 160 of cloud computing system 150 mayin fact be distributed across multiple data centers in differentlocations.

Each cloud computing environment 170 is associated with a particulartenant of cloud computing system 150, such as the enterprise providingvirtualized computing system 102. In one embodiment, cloud computingenvironment 170 may be configured as a dedicated cloud service for asingle tenant comprised of dedicated hardware resources 160 (i.e.,physically isolated from hardware resources used by other users of cloudcomputing system 150). In other embodiments, cloud computing environment170 may be configured as part of a multi-tenant cloud service withlogically isolated virtualized computing resources on a shared physicalinfrastructure. As shown in FIG. 1, cloud computing system 150 maysupport multiple cloud computing environments 170, available to multipleenterprises in single-tenant and multi-tenant configurations.

In one embodiment, virtualization environment 156 includes anorchestration component 158 (e.g., implemented as a process running in aVM) that provides infrastructure resources to cloud computingenvironment 170 responsive to provisioning requests. For example, if anenterprise required a specified number of virtual machines to deploy aweb applications or to modify (e.g., scale) a currently running webapplication to support peak demands, orchestration component 158 caninitiate and manage the instantiation of virtual machines (e.g., VMs172) on hosts 162 to support such requests. In one embodiment,orchestration component 158 instantiates virtual machines according to arequested template that defines one or more virtual machines havingspecified virtual computing resources (e.g., compute, networking,storage resources). Further, orchestration component 158 monitors theinfrastructure resource consumption levels and requirements of cloudcomputing environment 170 and provides additional infrastructureresources to cloud computing environment 170 as needed or desired. Inone example, similar to on-premise datacenter 102, virtualizationenvironment 156 may be implemented by running on hosts 162 VMwareESXi™-based hypervisor technologies provided by VMware, Inc. (althoughit should be recognized that any other virtualization technologies,including Xen® and Microsoft Hyper-V® virtualization technologies may beutilized consistent with the teachings herein).

In one embodiment, cloud computing system 150 may include a clouddirector 152 (e.g., run in one or more virtual machines) that managesallocation of virtual computing resources to an enterprise for deployingapplications. Cloud director 152 may be accessible to users via a REST(Representational State Transfer) API (Application ProgrammingInterface) or any other client-server communication protocol. Clouddirector 152 may authenticate connection attempts from the enterpriseusing credentials issued by the cloud computing provider. Cloud director152 maintains and publishes a catalog 166 of available virtual machinetemplates and packaged virtual machine applications that representvirtual machines that may be provisioned in cloud computing environment170. A virtual machine template is a virtual machine image that isloaded with a pre-installed guest operating system, applications, anddata, and is typically used to repeatedly create a VM having thepre-defined configuration. A packaged virtual machine application is alogical container of pre-configured virtual machines having softwarecomponents and parameters that define operational details of thepackaged application. An example of a packaged VM application is vApptechnology made available by VMware, Inc., although other technologiesmay be utilized. Cloud director 152 receives provisioning requestssubmitted (e.g., via REST API calls) and may propagates such requests toorchestration component 158 to instantiate the requested virtualmachines (e.g., VMs 172). One example of cloud director 152 is theVMware vCloud Director® produced by VMware, Inc.

In the embodiment of FIG. 1, cloud computing environment 170 supportsthe creation of a virtual data center 180 having a plurality of virtualmachines 172 instantiated to, for example, host deployed multi-tierapplications, as well as one or more virtualization managers 173(abbreviated as “Vman(s)”). A virtual data center 180 is a logicalconstruct that provides compute, network, and storage resources to anorganization. Virtual data centers 180 provide an environment where VM172 can be created, stored, and operated, enabling complete abstractionbetween the consumption of infrastructure service and underlyingresources. VMs 172 may be configured similarly to VMs 120, asabstractions of processor, memory, storage, and networking resources ofhardware resources 160. Virtualization managers 173 can be configuredsimilarly to virtualization manager 130.

Virtual data center 180 includes one or more virtual networks 182 usedto communicate between VMs 172 and managed by at least one networkinggateway component (e.g., gateway 184), as well as one or more isolatedinternal networks 186 not connected to gateway 184. Gateway 184 (e.g.,executing as a virtual appliance) is configured to provide VMs 172 andother components in cloud computing environment 170 with connectivity toexternal network 140 (e.g., Internet). Gateway 184 manages externalpublic IP addresses for virtual data center 180 and one or more privateinternal networks interconnecting VMs 172. Gateway 184 is configured toroute traffic incoming to and outgoing from virtual data center 180 andprovide networking services, such as firewalls, network addresstranslation (NAT), dynamic host configuration protocol (DHCP), and loadbalancing. Gateway 184 may be configured to provide virtual privatenetwork (VPN) connectivity over a network 140 with another VPN endpoint,such as a gateway 124 within on-premise datacenter 102. In otherembodiments, gateway 184 may be configured to connect to communicatewith on-premise datacenter 102 using a high-throughput, dedicated link(depicted as a direct connect 142) between on-premise datacenter 102 andcloud computing system 150. In one or more embodiments, gateways 124 and184 are configured to provide a “stretched” layer-2 (L2) network thatspans on-premise datacenter 102 and virtual data center 180, as shown inFIG. 1.

While FIG. 1 depicts a single connection between on-premise gateway 124and cloud-side gateway 184 for illustration purposes, it should berecognized that multiple connections between multiple on-premisegateways 124 and cloud-side gateways 184 may be used. Furthermore, whileFIG. 1 depicts a single instance of a gateway 184, it is recognized thatgateway 184 may represent multiple gateway components within cloudcomputing system 150. In some embodiments, a separate gateway 184 may bedeployed for each virtual data center, or alternatively, for eachtenant. In some embodiments, a gateway instance may be deployed thatmanages traffic with a specific tenant, while a separate gatewayinstance manages public-facing traffic to the Internet. In yet otherembodiments, one or more gateway instances that are shared among all thetenants of cloud computing system 150 may be used to manage allpublic-facing traffic incoming and outgoing from cloud computing system150.

In one embodiment, each virtual data center 180 includes a “hybridity”director module (depicted as hybridity director 174) configured tocommunicate with the corresponding hybrid cloud manager 132 inon-premise datacenter 102 to enable a common virtualized computingplatform between on-premise datacenter 102 and cloud computing system150. Hybridity director 174 (e.g., executing as a virtual appliance) maycommunicate with hybrid cloud manager 132 using Internet-based trafficvia a VPN tunnel established between gateways 124 and 184, oralternatively, using direct connection 142. In one embodiment, hybriditydirector 174 may control gateway 184 to control network traffic intovirtual data center 180. In some embodiments, hybridity director 174 maycontrol VMs 172 and hosts 162 of cloud computing system 150 viainfrastructure platform 154.

In an embodiment, hybrid cloud system 100 is configured for cross-systemVM migration between virtualized computing systems, such as cross-cloudVM migration between on-premise datacenter 102 and cloud computingsystem 150. In one example, on-premise datacenter 102 is the migrationsource and cloud computing system 150 is the migration destination.Alternatively, cloud computing system 150 can be the migration sourceand on-premise datacenter 102 can be the migration destination. Forpurposes of clarity by example, embodiments of cross-cloud VM migrationare described below with respect to the on-premise datacenter 102 beingthe migration source and the cloud computing system 150 being themigration destination. It is to be understood that the migration can bereversed using the same techniques.

Cross-cloud VM migration described herein enables users to seamlesslymove VMs between their on-premise datacenters and the public cloud.Cross-cloud VM migration includes both “cold migration” in which the VMis powered off during migration, as well as “hot migration” (alsoreferred to as live migration) in which the VM is powered on duringmigration. To facilitate cross-cloud VM migration, on-premise datacenter102 is configured with a mobility agent 190 and cloud computing system150 is configured with a mobility agent 192. Mobility agent 190 is usedas a destination of an on-premise VM migration. From the perspective ofthe on-premise datacenter 102, a target VM is migrated locally tomobility agent 190. Mobility agent 192 is used as a source of a cloud VMmigration. From the perspective of cloud computing system 150, mobilityagent 192 is a source VM to be migrated locally to a target host.Mobility agent 190 forwards VM migration traffic to mobility agent 192over a secure channel between gateway 124 and gateway 184.

Mobility agent 190 can be implemented using a VM in on-premisedatacenter 102 (e.g., a VM 120) or implemented directly on a hardwarecomputer system. Likewise, mobility agent 192 can be implemented using aVM in cloud computing system 150 (e.g., a VM 172) or implementeddirectly on a hardware computer system. Each mobility agent 190, 192includes a host simulator executing within an OS. That is, mobilityagent 190 can simulate a host 104 in on-premise data center 102, andmobility agent 192 can simulate a host 162 in cloud computing system150. A host simulator can simulate a host computer in terms of receivingand transmitting the appropriate messages to a virtualization managerthat make it appear as an actual host computer eligible for hosting VMs.Mobility agent 190 can be registered with virtualization manager 130 asan eligible host for VM migration within on-premise datacenter 102.Mobility agent 192 can be registered with virtualization manager 173 asan eligible host for VM migration within cloud computing system 150.Each mobility agent 190 and 192 functions as a proxy for VM migrationtraffic. Mobility agent 190 can function as a proxy for inbound VMmigration traffic within on-premise datacenter 102. Mobility agent 190can forward the VM migration traffic to mobility agent 192 through asecure channel established between gateways 124 and 184. Mobility agent192 functions as a proxy for outbound VM migration traffic within cloudcomputing system 150. Mobility agent 192 forwards the VM migrationtraffic to a destination host 162 within cloud computing system 150.

Within the cross-cloud VM migration workflow, the virtualization manager130 executes a local migration workflow between a source host andmobility agent 190, and a virtualization manager 173 executes a localmigration workflow between mobility agent 192 and a destination host.Each mobility agent 190 and 192 performs blocking and synchronizationbetween the concurrent local migration workflows. When a cross-cloud VMmigration is started, mobility agent 190 blocks the local VM migrationworkflow at the point where mobility agent 190 is prepared to receivedata from the source host. Likewise, mobility agent 192 blocks the localVM migration workflow at the point where mobility agent 192 is preparedto send data to the destination host. Once both mobility agents 190 and192 are synchronized, mobility agents 190 and 192 will unblock andproceed with the forwarding process.

Use of mobility agents 190 and 192 obviates the need to modify thevirtualization managers. The virtualization managers can perform thestandard local VM migration workflow, with the underlying logic forcross-cloud VM migration handled by mobility agents 190 and 192. VMmigration directly between a host in on-premise datacenter 102 and ahost in cloud computing system 150 would require implementation of VMmigration independent of the virtualization managers andre-implementation at the host-level of many functions performed by thevirtualization managers.

A cross-cloud VM migration can be initiated by hybrid cloud manager 132.When a cross-cloud VM migration is initiated, hybrid cloud manager 132can communicate with hybridity director 174 to process VM configurationdata, including translating infrastructure-dependent informationtherein, so that the migrated VM operates correctly after migration.

Hybrid cloud manager 132 can also create secure channels betweengateways 124 and 184 on-demand in order to route traffic associated withthe cross-cloud VM migration. The secure channels can be wide areanetwork (WAN) optimized and all traffic propagating therein can beencrypted. For WAN optimization, any of the WAN optimization techniquesdisclosed in U.S. patent application Ser. No. 14/838,537, filed Aug. 28,2015 and entitled “Data Center WAN Aggregation to Optimize Hybrid CloudConnectivity,” and U.S. patent application Ser. No. 14/838,572, filedAug. 28, 2015 and entitled “Pre-Fetch Cache Population for WANOptimization,” that can reduce latency and improve throughput may beemployed. One feature of local VM migration dictates that the migratedVM can retain its same network configuration post-migration. To managethis feature in cross-cloud VM migration, hybrid cloud manager 132 canconfigure the secure channels to implement a stretched layer-2 network,which allows the VM being migrated to retain its networkingconfiguration. For live migration, the network settings of thedestination VM are configured so that the destination VM is connected toan isolated internal network 186, not connected to gateway 184, so as toensure that after the live migration, sessions in the migrated VM can bekept alive and not dropped.

FIG. 2 is a block diagram showing logical connections and dataflow amongvarious components in hybrid cloud 100 with respect to a cross-cloud VMmigration according to an embodiment. Elements in FIG. 2 that are thesame or similar to those of FIG. 1 are designated with identicalreference numerals. FIG. 3 is a flow diagram depicting an embodiment ofa method 300 of migrating a virtualized computing instance, such as aVM, between source and destination virtualized computing systems, suchas between on-premise datacenter 102 and cloud computing system 150.FIG. 4 is a flow diagram depicting a method 302 of preparing cross-cloudVM migration according to an embodiment. Aspects of methods 300 and 302can be understood with respect to FIG. 2.

Referring to FIG. 3, method 300 includes the following high-level stepsperformed within hybrid cloud system 100: At method 302, hybrid cloudsystem 100 prepares for cross-cloud VM migration. As shown in FIG. 2, aVM 120 executing on a host 104 (the “source host”) in on-premisedatacenter 102 is to be migrated to cloud computing system 150. VM 120and host 104 are managed by virtualization manager 130. Host 104 isconnected to a network infrastructure 260 and a storage infrastructure262 in on-premise datacenter 102. Network infrastructure 260 includesvarious physical network devices that are used by host 104 and VM 120.Storage infrastructure 262 includes various physical storage devicesthat are used by host 104 and VM 120.

VM 120 includes a configuration 210 (also referred to as a VMconfiguration). A VM configuration includes various information andsettings for VM 120, such as the number of allocated virtual CPUs, theamount of allocated virtual memory, the amount of allocated virtualstorage, datastore location(s), network information, virtual hardwareinformation, and the like. Host 104 includes a hardware feature set 212.In particular, some portion of configuration 210 is independent ofnetwork infrastructure 260 and storage infrastructure 262. Anotherportion of configuration 210 is dependent on network infrastructure 260and storage infrastructure 262. This infrastructure-dependentconfiguration data includes settings that reference specific aspects ofnetwork infrastructure 260 and/or storage infrastructure 262.

Hardware feature set 212 includes the various hardware features of host104, such as CPU features, chipset features, memory features, storagefeatures, and the like. VM 120 can be configured to operate in amigration compatibility (MC) mode. In MC mode, an administratorestablishes MC data specifying a limited hardware feature set for VM120. Virtualization software on host 104 (e.g., hypervisor 116) willmask any features in hardware feature set 212 that are not specified bythe established MC data. Enforcement of MC mode for VM 120 aftermigration to cloud computing system 150 is described below.

Referring to FIG. 3, at step 304, hybrid cloud system 100 executescross-cloud VM migration to migrate VM 120 from on-premise datacenter102 to cloud computing system 150. At step 306, hybrid cloud system 100completes cross-cloud VM migration. Each of steps 302, 304, and 306 canbe performed by one or more components within hybrid cloud system 100.Thus, the hardware and software for performing method 300 is distributedacross on-premise datacenter 102 and cloud computing system 150. Examplecomponents and functions pertaining method 300 are described below.

FIG. 4 shows an example of method 302 for preparing for cross-cloud VMmigration. At step 402, when a cross-cloud VM migration is triggered(e.g., by an administrator), hybrid cloud manager 132 creates one ormore secure channels 220 (FIG. 2) between on-premise gateway 124 andcloud gateway 184. Each secure channel can be encrypted andWAN-optimized. At step 404, hybrid cloud manager 132 retrieves VMconfiguration 210 from virtualization manager 130 and sends VMconfiguration 210 to hybridity director 174 over a secure channel.Hybrid cloud manager 132 can perform various operations on VMconfiguration 210 prior to transfer to hybridity director 174, such asremoving, adding, and/or modifying information in VM configuration 210.Hybridity director 174 can perform various operations on VMconfiguration 210 prior initiating the migration, such as translatinginfrastructure-dependent information in VM configuration 210. Theprocessing of VM configuration 210 by hybrid cloud manager 132 and/orhybridity director 174 is described further below with respect to FIG.5.

At step 406, hybridity director 174 requests and obtains a destinationhost (e.g., a host 162) in cloud computing system 150 to execute themigrated VM. In an embodiment, hybridity director 174 can communicatewith cloud director 152 to request placement of the VM being migrated.In response, cloud director 152 can return a destination virtualizationmanager (e.g., a virtualization manager 173). Hybridity director 174 canthen cooperate with virtualization manager 173 to select a destinationhost (e.g., a host 162) for the migrated VM.

At step 408, hybridity director 174 can initialize cloud mobility agent192, and hybrid cloud manager 132 can initialize on-premise mobilityagent 190. At step 410, hybrid cloud manager 132 can establish a controlchannel 218 with cloud mobility agent 192 through on-premise gateway 124and cloud gateway 184. The control channel can be used to exchangestatus information and maintain synchronization between mobility agents,as described below.

FIG. 5 is a flow diagram depicting an example of a method 404 forprocessing VM configuration information. At step 502, hybrid cloudmanager 132 can sanitize VM configuration 210 before sending VMconfiguration 210 to hybridity director 174. Hybrid cloud manager 132can remove data related to VM state and/or on-premise datacenter statefor purposes of security. Such removed data can include, for example,datastore universal unique identifiers (UUIDs), storage paths, networkpaths, and the like. At step 504, hybrid cloud manager 132 can determinehardware features visible to VM 120 and add MC data to VM configuration210. As discussed above, VM 120 can be configured in an MC mode thatspecifies a limited set of hardware features to be supported. Hybridcloud manager 132 can detect the limited set of hardware featuresspecified by the MC mode and add MC data to VM configuration 210. Hybridcloud manager 132 can obtain MC data from host 104, from virtualizationmanager 130, or both.

At step 506, hybridity director 174 identifies infrastructure-dependentinformation in VM configuration 210. The infrastructure-dependentinformation includes mappings to on-premise infrastructure, such asmappings to network infrastructure 260 and/or mappings to storageinfrastructure 262. At step 508, hybridity director 174 translateson-premise infrastructure mappings in the infrastructure-dependentinformation to cloud infrastructure mappings. Notably, host 162 isconnected to a network infrastructure 264 and a storage infrastructure266 in cloud computing system 150. Network infrastructure 264 includesvarious physical network devices that are used by host 162 and VMstherein. Storage infrastructure 266 includes various physical storagedevices that are used by host 162 and VMs therein. Networkinfrastructure 264 can be different from network infrastructure 260.Likewise, storage infrastructure 266 can be different from storageinfrastructure 262. If VM 120 were to be migrated to host 162 withouttranslating infrastructure-dependent configuration information, then VM120 could function incorrectly or fail after migration is completed.Hybridity director 174 translates the infrastructure-dependentinformation so that VM 120 maintains the expected functionality, butwith respect to the cloud infrastructure rather than the on-premiseinfrastructure.

Returning to FIG. 4, in an embodiment, step 406 includes sub-steps 416and 418. At step 416, hybridity director 174 selects a destination hostsupporting hardware features specified in MC data of VM configuration210. Hosts 162 in cloud computing system 150 that do not support thelimited set of hardware features specified are removed fromconsideration. At step 418, hybridity director 174 cooperates withvirtualization software on a selected host 162 and/or withvirtualization manager 173 to mask any hardware features of thedestination host that are not present in the MC data of VM configuration210. Notably, the destination host can include more hardware featuresthan the source host. If the VM is migrated to a destination host havingmore hardware features, the VM can adopt the additional features. Thiscan operate to prevent the VM from being migrated back to the originalsource host, which does not have these additional hardware features. Anadministrator can configure VM 120 in an MC mode so that VM can bereadily migrated back to the original source host. Hybrid cloud manager132 can add MC data to VM configuration 210 sent to hybridity director174, and hybridity director 174 can direct virtualization manager 173and/or the destination host to mask any features not present in thespecified limited set of hardware features.

In an embodiment, step 408 includes sub-steps 420 and 422. At step 420,hybrid cloud manager 132 configures on-premise mobility agent 190 basedon VM configuration 210. That is, on-premise mobility agent 190 isconfigured to simulate a host having the same or substantially similarfeatures as the source host.

As shown in FIG. 2, on-premise mobility agent 190 can include a hostsimulator 202. Host simulator 202 simulates a host and is configurablethrough an application programming interface (API) 203. Hybrid cloudmanager 132 can configure host simulator 202 through API 203 and add thesimulated host to the inventory of virtualization manager 130. Tovirtualization manager 130, the simulated host appears as any other hostwithin on-premise datacenter. This allows host simulator 202 to act as adestination during the on-premise migration workflow. Host simulator 202functions as a proxy for communication between host 104 and a migrationservice 270 in gateway 124. Migration service 270 is cooperates withmigration service 272 in gateway 184 to exchange migration trafficduring the migration operation.

At step 422, hybridity director 174 configures cloud mobility agent 192to implement a VM 120M based on VM configuration 210. Initially, VM 120Mis a “seed VM.” After migration, VM 120M will be a fully functionalreplica of VM 120. As shown in FIG. 2, cloud mobility agent 192 caninclude a host simulator 204. Host simulator 204 simulates a host and isconfigurable through an API 206. Hybridity director 174 can configurehost simulator 204 through API 206 and add the simulated host to theinventory of virtualization manager 173. To virtualization manager 173,the simulated host appears as any other host within cloud computingsystem 150. In addition, hybridity director 174 provides VMconfiguration 210 to host simulator 204 (e.g., through API 206). Hostsimulator 204 creates VM 120M based on VM configuration (as modified asdescribed in FIG. 5). Thus, VM 120M includes a configuration the same asor substantially the same as VM configuration 210. Hybridity director174 can add VM 120M to the inventory managed by virtualization manager173. This allows VM 120M to act as a destination during the cloudmigration workflow.

Returning to FIG. 3, the cross-cloud VM migration is executed duringstep 304. In an embodiment, step 304 includes various sub-steps. At step308, hybrid cloud manager 132 directs virtualization manager 130 toexecute an on-premise migration workflow. For the on-premise migrationworkflow, the VM being migrated is VM 120, the source host is host 104,and the destination host is a host simulated by host simulator 202 inon-premise mobility agent 190. The on-premise migration workflow itselfcan include preparation, execution, and completion steps similar to thecross-cloud VM workflow. In an embodiment, during preparation, theon-premise migration workflow can include various compatibility checks(step 312). Virtualization manager 130 executes the compatibility checksto ensure that VM 120 can be migrated to the specified destination host.As discussed above, hybrid cloud manager 132 configures host simulator202 to simulate a host capable of executing VM 120 based on VMconfiguration 210. This allows the compatibility checks performed byvirtualization manager 130 to be satisfied.

At step 310, hybridity director 174 directs virtualization manager 173to execute a cloud migration workflow. For the cloud migration workflow,the source host is a host simulated by host simulator 204 in cloudmobility agent 192, and the destination host is a host 162. The cloudmigration workflow, similar to the on-premise migration workflow,includes preparation, execution, and completion steps. In an embodiment,during preparation, the cloud migration workflow can include variouscompatibility checks (step 314). Virtualization manger 173 executes thecompatibility checks to ensure that VM 120M can be executed on thespecified destination host.

The on-premise and cloud migration workflows are executed concurrently.During execution of the two concurrent workflows, some steps of oneworkflow can depend on performance of other steps in the other workflow.For example, the on-premise migration workflow can proceed up until thepoint at which on-premise mobility agent 190 is ready to receivemigration data from the source host. Mobility agent 190 can block theon-premise migration workflow at that point until receiving confirmationthat mobility agent 192 is ready to receive the migration data. Inanother example, the cloud migration workflow can proceed up until thepoint at which the cloud mobility agent 192 is ready to receivemigration data over the network. Mobility agent 192 can block the cloudmigration workflow at that point until receiving confirmation thatmobility agent 190 is ready to send the migration data. These areexample blocking points and the respective workflows can include otherblocking points. The on-premise migration workflow and the cloudmigration workflow can perform steps 316 and 318, respectively, in orderto synchronize the on-premise migration workflow with the cloudmigration workflow.

At step 320, on-premise mobility agent 190 transfers migration trafficto cloud mobility agent 192 over one or more secure channel(s)established between gateways 124 and 184. Step 320 can include sub-steps324 and 326. At step 324, on-premise mobility agent 190 can filter oneor more portions of the migration traffic from being sent to cloudmobility agent 192. For example, on-premise mobility agent 190 canfilter various identifiers that pertain only to on-premise datacenter102. On-premise mobility agent 190 can insert dummy data in place of thefiltered portions (e.g., dummy IDs). At step 326, cloud mobility agent192 can replace one or more portions of the migration traffic. Forexample, cloud mobility agent 192 can insert identifiers that pertain tocloud computing system 150 in place of dummy identifiers inserted byon-premise mobility agent 190 in step 324.

Step 306 can include sub-steps 328 and 330. At step 328, after migrationis complete, virtualization manager 130 can remove VM 120 from itsinventory. At step 330, host 162 can execute a VM 120M, which is amigration of VM 120. In addition, for live migration, the migrated VM islive imported into the inventory maintained by virtualization manager173 to make the migrated VM visible on the destination side.

It is to be understood that at least a portion of the various steps andsub-steps shown in FIGS. 3 and 4 can be executed concurrently. That is,while some steps/sub-steps can be executed sequentially, othersteps/sub-steps can be executed concurrently. The arrangement ofsteps/sub-steps in FIGS. 3 and 4 is not meant to convey any particularsequential/concurrent arrangement other than as required by thefunctional description above.

The cross-cloud VM migration workflow described with respect to FIGS.2-5 can be used to migrate a VM from one virtualized computing system toanother. In the example above, a VM is migrated from on-premisedatacenter 102 to cloud computing system 150. However, in otherexamples, a VM can be migrated from cloud computing system 150 toon-premise datacenter 102 using a similar process. Further, thecross-cloud VM migration workflow described herein encompasses both hotand cold migrations. Embodiments also employ a migration schedulerrunning as part of virtualization manager 130 to schedule livemigrations of VMs in view of the latency and throughput of the networkbetween the source and the destination, and in view of any improvementsin the latency and throughput that can be achieved through WANoptimization techniques. For example, for a live VM migration that is ofhigh priority, the migration scheduler may schedule just that one VM forlive migration and throttle (delay) other live migrations until the highpriority migration has completed. If WAN optimization techniques improvethe latency and throughput of the network between the source and thedestination, the number of parallel live VM migrations may be increasedaccordingly. Further, when live migrating from a multi-tenant cloud, inwhich different tenants might schedule live migrations at similar times,the migration scheduler staggers the live migrations so that each livemigration can be carried out with low enough latency and high enoughthroughput that the live migration can converge and be completed withina reasonable amount of time.

FIG. 6 is a block diagram depicting an example of a computer system 600in which one or more embodiments of the present disclosure may beutilized. Computer system 600 can be used as a host to implement hybridcloud manager 132, hybridity director 174, or other component describedabove. Computer system 600 includes one or more central processing units(CPUs) 602, memory 604, input/output (TO) circuits 606, and varioussupport circuits 608. Each of CPUs 602 can include any microprocessorknown in the art and can execute instructions stored on computerreadable storage, such as memory 604. Memory 604 can include variousvolatile and/or non-volatile memory devices, such as random accessmemory (RAM), read only memory (ROM), and the like. Instructions anddata 610 for performing the various methods and techniques describedabove can be stored in memory 604 for execution by CPUs 602. That is,memory 604 can store instructions executable by CPUs 602 to perform oneor more steps/sub-steps described above in FIGS. 3, 4, and 5. Supportcircuits 608 include various circuits used to support operation of acomputer system as known in the art.

According to embodiments, hybrid cloud computing system 100 includes acomponent on the management plane that bootstraps mobility agents 190,192, and communicates with hybrid cloud manager 132 and hybriditydirector 174 to extract and inject a VM from one endpoint and into theother while maintaining the same management state. As a result, the VMmigration can happen to/from different compute platform (e.g., vSphere)versions. Without such a feature, version incompatibility couldconstrain some VM migration opportunities.

The various embodiments described herein may employ variouscomputer-implemented operations involving data stored in computersystems. For example, these operations may require physical manipulationof physical quantities—usually, though not necessarily, these quantitiesmay take the form of electrical or magnetic signals, where they orrepresentations of them are capable of being stored, transferred,combined, compared, or otherwise manipulated. Further, suchmanipulations are often referred to in terms, such as producing,identifying, determining, or comparing. Any operations described hereinthat form part of one or more embodiments of the invention may be usefulmachine operations. In addition, one or more embodiments of theinvention also relate to a device or an apparatus for performing theseoperations. The apparatus may be specially constructed for specificrequired purposes, or it may be a general purpose computer selectivelyactivated or configured by a computer program stored in the computer. Inparticular, various general purpose machines may be used with computerprograms written in accordance with the teachings herein, or it may bemore convenient to construct a more specialized apparatus to perform therequired operations.

The various embodiments described herein may be practiced with othercomputer system configurations including hand-held devices,microprocessor systems, microprocessor-based or programmable consumerelectronics, minicomputers, mainframe computers, and the like.

One or more embodiments of the present invention may be implemented asone or more computer programs or as one or more computer program modulesembodied in one or more computer readable media. The term computerreadable medium refers to any data storage device that can store datawhich can thereafter be input to a computer system—computer readablemedia may be based on any existing or subsequently developed technologyfor embodying computer programs in a manner that enables them to be readby a computer. Examples of a computer readable medium include a harddrive, network attached storage (NAS), read-only memory, random-accessmemory (e.g., a flash memory device), a CD (Compact Discs)—CD-ROM, aCD-R, or a CD-RW, a DVD (Digital Versatile Disc), a magnetic tape, andother optical and non-optical data storage devices. The computerreadable medium can also be distributed over a network coupled computersystem so that the computer readable code is stored and executed in adistributed fashion.

Although one or more embodiments of the present invention have beendescribed in some detail for clarity of understanding, it will beapparent that certain changes and modifications may be made within thescope of the claims. Accordingly, the described embodiments are to beconsidered as illustrative and not restrictive, and the scope of theclaims is not to be limited to details given herein, but may be modifiedwithin the scope and equivalents of the claims. In the claims, elementsand/or steps do not imply any particular order of operation, unlessexplicitly stated in the claims.

Virtualization systems in accordance with the various embodiments may beimplemented as hosted embodiments, non-hosted embodiments or asembodiments that tend to blur distinctions between the two, are allenvisioned. Furthermore, various virtualization operations may be whollyor partially implemented in hardware. For example, a hardwareimplementation may employ a look-up table for modification of storageaccess requests to secure non-disk data.

Certain embodiments as described above involve a hardware abstractionlayer on top of a host computer. The hardware abstraction layer allowsmultiple contexts to share the hardware resource. In one embodiment,these contexts are isolated from each other, each having at least a userapplication running therein. The hardware abstraction layer thusprovides benefits of resource isolation and allocation among thecontexts. In the foregoing embodiments, virtual machines are used as anexample for the contexts and hypervisors as an example for the hardwareabstraction layer. As described above, each virtual machine includes aguest operating system in which at least one application runs. It shouldbe noted that these embodiments may also apply to other examples ofcontexts, such as containers not including a guest operating system,referred to herein as “OS-less containers”. OS-less containers implementoperating system-level virtualization, wherein an abstraction layer isprovided on top of the kernel of an operating system on a host computer.The abstraction layer supports multiple OS-less containers eachincluding an application and its dependencies. Each OS-less containerruns as an isolated process in userspace on the host operating systemand shares the kernel with other containers. The OS-less containerrelies on the kernel's functionality to make use of resource isolation(CPU, memory, block I/O, network, etc.) and separate namespaces and tocompletely isolate the application's view of the operating environments.By using OS-less containers, resources can be isolated, servicesrestricted, and processes provisioned to have a private view of theoperating system with their own process ID space, file system structure,and network interfaces. Multiple containers can share the same kernel,but each container can be constrained to only use a defined amount ofresources such as CPU, memory and I/O. The term “virtualized computinginstance” as used herein is meant to encompass both VMs and OS-lesscontainers.

Many variations, modifications, additions, and improvements arepossible, regardless the degree of virtualization. The virtualizationsoftware can therefore include components of a host, console, or guestoperating system that performs virtualization functions. Pluralinstances may be provided for components, operations or structuresdescribed herein as a single instance. Boundaries between variouscomponents, operations and data stores are somewhat arbitrary, andparticular operations are illustrated in the context of specificillustrative configurations. Other allocations of functionality areenvisioned and may fall within the scope of the invention(s). Ingeneral, structures and functionality presented as separate componentsin exemplary configurations may be implemented as a combined structureor component. Similarly, structures and functionality presented as asingle component may be implemented as separate components. These andother variations, modifications, additions, and improvements may fallwithin the scope of the appended claim(s).

We claim:
 1. A method of migrating a first virtualized computinginstance between source and destination virtualized computing systems,comprising: executing a first migration workflow in the sourcevirtualized computing system where a host computer in the sourcevirtualized computing system executing the first virtualized computinginstance is a source host in the first migration workflow and a firstmobility agent running in a second virtualized computing instance in thesource virtualized computing system simulates, in the first migrationworkflow, a destination host able to receive and transmit messages so asto appear eligible for hosting virtualized computing instances; blockingthe first migration workflow by the first mobility agent at a firstpoint; executing a second migration workflow in the destinationvirtualized computing system, where a second mobility agent running in athird virtualized computing instance in the destination virtualizedcomputing system simulates a source host in the second migrationworkflow and a host computer in the destination virtualized computingsystem is a destination host in the second migration workflow; blockingthe first migration workflow by the first mobility agent at a firstpoint; sending a configuration of the first virtualized computinginstance from the source virtualized computing system to the destinationvirtualized computing system; translating, as part of the secondmigration workflow, infrastructure-dependent information in theconfiguration of the first virtualized computing instance, where theinfrastructure-dependent information in the configuration of the firstvirtualized computing instance that is translated includes settingsrelating to at least one of a network infrastructure or a storageinfrastructure in the source virtualized computing system; andunblocking the first and second migration workflows once the first andsecond migration workflows are synchronized at a point where both thefirst and second migration workflows can be executed concurrently;transferring, after the first and second migration workflows areunblocked, migration data including the first virtualized computinginstance between the first mobility agent and the second mobility agentover a network.
 2. The method of claim 1, wherein the source virtualizedcomputing system includes a first network infrastructure, wherein thedestination virtualized computing system includes a second networkinfrastructure, and wherein the infrastructure-dependent informationincludes mappings to the first network infrastructure.
 3. The method ofclaim 2, wherein the step of translating comprises replacing themappings to the first network infrastructure with mappings to the secondnetwork infrastructure.
 4. The method of claim 1, wherein the sourcevirtualized computing system includes a first storage infrastructure,wherein the destination virtualized computing system includes a secondstorage infrastructure, and wherein the infrastructure-dependentinformation includes mappings to the first storage infrastructure. 5.The method of claim 4, wherein the step of translating comprisesreplacing the mappings to the first storage infrastructure with mappingsto the second storage infrastructure.
 6. The method of claim 1, furthercomprising: creating a secure channel through the network between afirst gateway in the source virtualized computing system and a secondgateway in the destination virtualized computing system; and sending theconfiguration of the first virtualized computing instance from thesource virtualized computing system to the destination virtualizedcomputing system over the secure channel.
 7. The method of claim 6,further comprising: removing data from the configuration prior tosending the configuration to the destination virtualized computingsystem.
 8. A computer system, comprising: a source virtualized computingsystem and a destination virtualized computing system; memory configuredto store code; and one or more processors in the source and thedestination virtualized computing systems, the one or more processorsbeing configured to execute the code to: execute a first migrationworkflow in the source virtualized computing system, where a hostcomputer in the source virtualized computing system executing a firstvirtualized computing instance is a source host in the first migrationworkflow and a first mobility agent running in a second virtualizedcomputing instance in the source virtualized computing system simulates,in the first migration workflow, a destination host able to receive andtransmit messages so as to appear eligible for hosting virtualizedcomputing instances; block the first migration workflow by the firstmobility agent at a first point; execute a second migration workflow inthe destination virtualized computing system, where a second mobilityagent running in a third virtualized computing instance in thedestination virtualized computing system simulates a source host in thesecond migration workflow and a host computer in the destinationvirtualized computing system is a destination host in the secondmigration workflow; block the second migration workflow by the secondmobility agent at a second point; send a configuration of the firstvirtualized computing instance from the source virtualized computingsystem to the destination virtualized computing system; translate, aspart of the second migration workflow, infrastructure-dependentinformation in the configuration of the first virtualized computinginstance, where the infrastructure-dependent information in theconfiguration of the first virtualized computing instance that istranslated includes settings relating to at least one of a networkinfrastructure or a storage infrastructure in the source virtualizedcomputing system; and unblock the first and second migration workflowsonce the first and second migration workflows are synchronized at apoint where both the first and second migration workflows can beexecuted concurrently; transfer, after the first and second migrationworkflows are unblocked, migration data including the first virtualizedcomputing instance between the first mobility agent and the secondmobility agent over a network.
 9. The computer system of claim 8,wherein the source virtualized computing system includes a first networkinfrastructure, wherein the destination virtualized computing systemincludes a second network infrastructure, and wherein theinfrastructure-dependent information includes mappings to the firstnetwork infrastructure.
 10. The computer system of claim 9, wherein theone or more processors are further configured to execute the code toreplace the mappings to the first network infrastructure with mappingsto the second network infrastructure.
 11. The computer system of claim8, wherein the source virtualized computing system includes a firststorage infrastructure, wherein the destination virtualized computingsystem includes a second storage infrastructure, and wherein theinfrastructure-dependent information includes mappings to the firststorage infrastructure.
 12. The computer system of claim 11, wherein theone or more processors are further configured to execute the code toreplace the mappings to the first storage infrastructure with mappingsto the second storage infrastructure.
 13. The computer system of claim8, wherein the one or more processors are further configured to executethe code to: create a secure channel through the network between a firstgateway in the source virtualized computing system and a second gatewayin the destination virtualized computing system; and send theconfiguration of the first virtualized computing instance from thesource virtualized computing system to the destination virtualizedcomputing system over the secure channel.
 14. The computer system ofclaim 13, wherein the one or more processors are further configured toexecute the code to: remove data from the configuration prior to sendingthe configuration to the destination virtualized computing system.
 15. Anon-transitory computer readable medium comprising instructions, whichwhen executed in a computer system, causes the computer system to carryout a method of migrating a first virtualized computing instance betweensource and destination virtualized computing systems, the methodcomprising: executing a first migration workflow in the sourcevirtualized computing system, where a host computer in the sourcevirtualized computing system executing the first virtualized computinginstance is a source host in the first migration workflow and a firstmobility agent running in a second virtualized computing instance in thesource virtualized computing system simulates, in the first migrationworkflow, a destination host able to receive and transmit messages so asto appear eligible for hosting virtualized computing instances; blockingthe first migration workflow by the first mobility agent at a firstpoint; executing a second migration workflow in the destinationvirtualized computing system, Where a second mobility agent running in athird virtualized computing instance in the destination virtualizedcomputing system simulates a source host in the second migrationworkflow and a host computer in the destination virtualized computingsystem is a destination host in the second migration workflow; blockingthe second migration workflow by the second mobility agent at a secondpoint; sending a configuration of the first virtualized computinginstance from the source virtualized computing system to the destinationvirtualized computing system; translating, as part of the secondmigration workflow, infrastructure-dependent information in theconfiguration of the first virtualized computing instance, where theinfrastructure-dependent information in the configuration of the firstvirtualized computing instance that is translated includes settingsrelating to at least one of a network infrastructure or a storageinfrastructure in the source virtualized computing system; andunblocking the first and second migration workflows once the first andsecond migration workflows are synchronized at a point where both thefirst and second migration workflows can be executed concurrently;transferring, after the first and second migration workflows areunblocked, migration data including the first virtualized computinginstance between the first mobility agent and the second mobility agentover a network.
 16. The non-transitory computer readable medium of claim15, wherein the source virtualized computing system includes a firstnetwork infrastructure, wherein the destination virtualized computingsystem includes a second network infrastructure, and wherein theinfrastructure-dependent information includes mappings to the firstnetwork infrastructure.
 17. The non-transitory computer readable mediumof claim 16, wherein the step of translating comprises replacing themappings to the first network infrastructure with mappings to the secondnetwork infrastructure.
 18. The non-transitory computer readable mediumof claim 15, wherein the source virtualized computing system includes afirst storage infrastructure, wherein the destination virtualizedcomputing system includes a second storage infrastructure, and whereinthe infrastructure-dependent information includes mappings to the firststorage infrastructure.
 19. The non-transitory computer readable mediumof claim 18, wherein the step of translating comprises replacing themappings to the first storage infrastructure with mappings to the secondstorage infrastructure.
 20. The non-transitory computer readable mediumof claim 15, the method further comprising: removing data from theconfiguration prior to sending the configuration to the destinationvirtualized computing system.